\section*{Run 4}
\subsection*{Modules to decompose}
The module we are going to decompose in this run is Other Functionality.

\subsection*{Choose architectural drivers}
\begin{itemize}
\item Av3: Third Party Billing Service failure
\item M1: Dynamic pricing
\item UC14: Request consumption prediction
\item UC15: Generate invoice
\item UC16: Mark invoice paid
\end{itemize}

This run mostly focuses on the aspects of payments, billing and dynamic pricing.

\subsection*{Choose architectural patterns}

Availability tactics (Av3):
\begin{itemize}
\item Fault detection: Ping/Echo. When the bill is send to the third party, it should receive a confirmation.
%\item Fault recovery: To us active redundancy seems the best solution to the fault recovery problem. The database must have an availability of 99.9%. 
\item Fault prevention: ReMeS has negotiated a Service-Level Agreement with the third party billing service.
\end{itemize}

%Modifiability tactics (M1):
%\begin{itemize}
%\item Resource demand: Increasing the computational efficiency. If the efficiency to detect anomalies goes up, the performance goes up.
%\end{itemize}

%Patterns
%\begin{itemize}
% Momenteel geen patterns voor run 4
%\end{itemize}

\subsection*{Modules}

\begin{itemize}
\item Billing Service: This component takes care of all the billings. It has the ability to read measurement data and pricing data from the database to make the bill. Based on this information it makes a bill and sends it to the third party billing service. If this fails to often, the component will notify a ReMeS operator. When the bill is paid the third party billing service can tell this to ReMeS and ReMeS can store this in the database.
\item UIS Interface: This is the interface for the UIS. The UIS can use this to request consumption predictions and to update their prices. This component will then let all the needed customers know with Send Price Notification and sends a price update command through the Command Sender component to the configured smart devices and home automation systems.
\item Consumption Predictor: This component uses data from the database and different algorithms to determine the consumption over a certain period. It stores this results in the database. Every now and then it fetches the data and processes data over a predefined time, but it also has an interface to allow components to recalculate the prediction over a specific time that the component decides.
\end{itemize}

\begin{figure}
  \centering
    \includegraphics[width=\textwidth, angle=90]{addRuns/ADDRun4.pdf}
  \caption{Run 4: Level 2 and level 3 decomposition of the ReMeS system}
  \label{addRun4}
\end{figure}

\subsection*{Define interfaces}

\begin{center}
    \begin{longtable}{ | p{4cm} | p{2,5cm} | p{8,5cm} |}
    \hline
    Component & Interface & Operations \\ \hline
    Billing Service & iBillingService & \begin{itemize} \item \textbf{markPaidBill(BillId id)} \end{itemize}  \\ \hline
    UIS Interface & iUISInterface & \begin{itemize} \item \textbf{updatePrices(Price p)} \item \textbf{updatePrices(Price p, Customer c)} \item \textbf{requestConsumptionPrediction()} \item \textbf{requestConsumptionPrediction(Time t)} \end{itemize}  \\ \hline
    Consumption Predictor & iConsPred & \begin{itemize} \item \textbf{updateConsumptionPrediction(Time)} \end{itemize}     \\ \hline
    Notification Handler & iNotificationHandler & \begin{itemize} \item sendAlarmNotification(Module m, Details d) \item sendIssueNotification(Details d) \item sendAnomalyNotification(Module m, Details d) \item \textbf{sendInfoNotification(Customer c, Details d)} \end{itemize} \\  \hline
    Command Sender & iCommandSender & \begin{itemize} \item actuateValve(Module m) \item processConfirmTrame(Trame t) \item sendAck(Module m, Trame t) \item \textbf{updatePrice(Customer c, Price p)} \end{itemize} \\ \hline
    \end{longtable}
\end{center}

\newpage
\begin{itemize}
\item We can see that the updatePrice has 2 different interfaces for the method. The first is to update the price to all the customers that are subscribed to the dynamic pricing. The second methods allows the UIS to pass on a customer to give that specific customer a price update. The UIS can have specific contracts with companies with their own price agreements. Through this interface they only apply the price update to that customer.
\item The requestConsumptionPrediction also has 2 interfaces. One is to request a static predefined version of the consumption prediction. The other one allows the UIS to ask for a more time specific consumption prediction. The first one is faster, because ReMeS only needs to get the prediction from the database, whereas the second method needs to recalculate the prediction.
\item The Consumption predictor has an interface to allow components to ask for an updated version of the consumption prediction over a specified time.
\end{itemize} 

\begin{figure}[h]
  \centering
    \includegraphics[width=\textwidth]{addRuns/Run4.png}
  \caption{Run 4: The addition of the Billing Service, UIS Interface and Consumption Predictor components to the second level decomposition}
  \label{run4}
\end{figure}

\subsection*{Verify and refine}
M1 is mainly covered. We still need to implement the ability for the user to change the pricing from static to dynamic and the other way around. Reconfiguration of modules is not yet implemented, this is on the to do list of the next ADD run. Av3 is covered. When we look at UC14 everything seems to be covered. Consumption prediction can be done. ReMeS can generate invoices and has the ability to mark them as paid, so that covers UC15 and UC16.

\paragraph*{Requirements that are now completely covered:}
\begin{itemize}
\item Av1: Measurement database failure
\item Av2: Missing measurements
\item \textbf{Av3: Third Party Billing Service failure}
\item P1: Timely closure of valves
\item P2: Anomaly Detection
\item P3: Requests to the measurement database
\item \textbf{M1: Dynamic pricing}
\item UC7: Send trame to remote device
\item UC8: Send measurement
\item UC9: Notify customer
\item UC10: Detect anomaly
\item UC13: Send alarm
\item \textbf{UC14: Request consumption predictions}
\item \textbf{UC15: Generate invoice}
\item \textbf{UC16: Mark invoice paid}
\end{itemize}

\subsection*{Remarks}
\begin{itemize}
\item The consumption prediction can be implemented that for that each UIS the time is remembered. So lets say if the UIS requests a prediction for the next week, the consumption predictor remembers that choice and from then on always makes a prediction for the next week. If the UIS changes the time, the predictor changes as well.
%\item UC15 (5) ReMeS needs to ask the UIS for the price over a specific time and then puts it in the DB. We implemented this a little differently. When the UIS does a price update via the UIS interface, this price update is stored in the DB. This makes sure that we do not need to contact the UIS again for data it has already provided to ReMeS.
%TODO prijs informatie op maat kan daardoor niet verkregen worden (bvb kortingen per gebruiker)
%Ook een veresite in M1 !
\item When a bill is created, this bill is passed to the Third Party Billing service and placed in the database. The Third Party Billing service uses the bill's ID to let ReMeS know of payment. 
\end{itemize}